分布式系统有三大指标
consistency
availability
partition tolerance
他们的第一个指标分别是 C、A、P
这三个指标不能同时做到，这个结论就叫做 CAP 定理
Consistency
consistency：一致性
consistency 在分布式系统中的意思是写操作之后的读操作必须返回该值，这种说法在普通系统上可以说是毋庸置疑的，但是分布式系统拥有多台服务器，所以这就涉及到多台服务器之间的同步问题。
比如说，当客户端向 G1 发送消息，将 v0 的值更改为 v1，当 G1 的值更改完成后，G1 会发送消息到 G2，将 G2 中 v0 的值也更改为 v1。之后客户端向 G2 请求该值时得到的也是 V1，这就实现了分区之间的同步，也就是分区之间的一致性
即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。一致性的问题在并发系统中不可避免，对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。
Availability
Availability：可用性
可用性的意思是说只要收到用户的请求，服务器就必须给出回应。
用户可以选择向 G1 或 G2 发起操作。不管是哪台服务器，只要收到请求，就必须告诉用户操作结果，否则就满足不了可用性。
总结一下就是服务一直可用，而且是正常响应时间。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。
Partition tolerance
partition tolerance：分区容错
大多数分布式系统都分布在多个子网络中，每个子网络就叫做一个区。分区容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美国，这就是两个区，它们之间的通信是可能失败的。
上图中 client 向 G1 发送一条消息，如果 G1 和 G2 之间的通讯异常，则 G1 无法将更改信息同步到 G2 上，这就会导致两个分区服务器的信息不一致，而这种情况在设计分布式系统时是必须考虑到的。
即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。
分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。
CAP 定理的证明
首先，在现实环境下，网络错误的情况是一直存在的，也就是说 CAP 中的 P 是一直成立的。
那么假设如下情况：当 用户向 G1 发送更新信息后，又有用户向 G2 发送请求信息，但是这时候两台服务器之间的网络出现异常，更新的信息无法同步。这时候应该怎么办呢？这时候有两种方法：
一是牺牲数据一致性，响应旧的数据给用户
二是牺牲可用性，阻塞等待直到网络连接恢复，数据更新完成后再进行返回
上面的两种情况很简单，但也说明在分布式系统中只能在一致性和可用性二者中选其一。也就是说分布式系统不能同时满足 CAP 三个特性。这就需要进行取舍了。
取舍策略
CAP 三个特性只能满足其中两个，那么取舍策略就共有三种：
CA without P：如果不要 P（不允许分区），则 C（强一致性）和 A（可用性）是可以保证的。但放弃 P 的同时也就意味着放弃了系统的扩展性，这是违背分布式系统设计的初衷的
CP without A：如果不要求 A，相当于每个请求都需要在服务器之间保持一致，而 P 会导致同步时间无限延长（也就是等待数据同步完才能正常访问服务），一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据一致了之后再让用户访问系统。设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。
AP without C：要高可用并允许分区，则放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据不一致。典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。